User mobility and delay sensitive data traffic (e.g., Voice Over Internet Protocol (VoIP)) are two expanding areas within communication systems. To guarantee user mobility in and between mobile communications networks, handover between access routers of the network is an important issue. Wireless networking (which is by definition mobile) and data networking are also converging. Therefore, it is necessary to find the solution for safely transporting delay sensitive data traffic to mobile nodes as they move within or between the communications systems. As the number of mobile users grows, the demand for delay sensitive applications, such as audio streaming, video conference, etc., increases as well.
Furthermore, the communications systems represent a multi-vendor environment. In that context, user mobility is only guaranteed by interoperability of the various equipments. Thus, handover mechanisms, while they can be improved or tweaked within a given vendors' product line, need a common basis on which to rely. Mobile IPv6 (MIPv6; see Internet Engineering Task Force (IETF) RFC 3775 herein included by reference) is one of the standardized protocols that can provide such a common basis.
In the context of Mobile IPv6, when a Mobile Node (MN) enters a new network, it can wait for a Router Advertisement (RtAdv) message, which are sent periodically by access routers, or actively request the RtAdv by sending a Router Solicitation (RtSol) message. The RtAdv message comprises the identity of the emitting access router and further information necessary for the MN to form a Care-of Address (CoA) that it will use in the newly entered network while being connected to the emitting access router. Once the CoA is determined, the MN performs multiple tasks before being able to use the CoA:                a Duplicated Address Detection (DAD) test is performed (e.g., by sending Neighbor Solicitation (NS) to verify the uniqueness of the CoA;        a Return Routability (RR) test is performed to verify the reachability of its new CoA;        a Binding Management Key (Kbm) is created by the MN to be used during a session with eventual Correspondent Nodes (CN); and        a Binding Update (BU) message is sent to the MN's Home Agent (HA) and/or CN, which in turn sends a Binding Acknowledgement (BA) message.        
When the MN moves from its current access router towards a second access router, many, if not all, of the preceding steps occur in relation to a RtAdv message issued from the second access router, thereby completing a handover from the current access router to the second access router. The handover happens between different subnets associated to their respective access router. Because of the various tasks performed by the MN, the handover procedure results in a user-perceptible deterioration, especially in delay sensitive applications. For instance, if a MN is involved in a communication with a CN and moves between subnets, it has to send BUs towards its HA and CN. Since the HA and or CN can be located far away from the MN, the round-trip transmission delay will affect the quality of the communication (e.g., because of packet drops and delays of RR or DAD).
Hierarchical MIPv6 (HMIPv6; see IETF RFC 4140 herein included by reference) is improving on the conventional MIPv6 protocol by minimizing the number of BU/BA exchanges needed between the MN and its home network. It provides what can be referred to as a local Home Agent named Mobility Anchor Point (MAP) defining a MAP domain within which the MN is free to move without informing its HA. A regional CoA (rCoA) is added to the MN within the MAP domain. The MIPv6 CoA is replaced with a local CoA (lCoA), which is defined under the access router just as the conventional CoA. When the MN enters the MAP domain, a RtAdv is received (following RtSol or not) comprising information necessary to form the rCoA and the lCoA. A Kbm is computed and DAD and RR tests are performed on both the rCoA and lCoA addresses. More precisely, a first RR test is performed on the rCoA between MN and CN and, during this RR test, the Kbm is computed. The MAP also performs DAD for the MN's rCoA and the MN performs DAD its lCoA. A Secutiry Association (SA) is further established between the MN and the MAP using any key establishment protocols such as Internet Key Exchange (IKE). The rCoA is registered with the HA with a conventional BU/BA exchange and the lCoA is registered with the MAP via a local BU (LBU)/BA (BA) exchange. When the MN moves within the MAP domain between access routers, it registers changes to its lCoA with the MAP via LBU/BA without having to contact the HA. Depending on implementations, the MN may or not use its lCoA during a communication with a CN. If it uses its lCoA with the CN, a conventional BU/BA exchange is needed following modification of its lCoA. If the rCoA is used towards the CN, then no BU/BA exchange is needed in case of intra-MAP domain handover. HMIPv6 further necessitates new DAD for each change of lCoA.
The handover procedure in HMIPv6 is improved compared to MIPv6. However, among other things, there are still delays and packet loss induced upon changing the lCoA that are not acceptable for delay sensitive applications. Furthermore, the HMIPv6 does not provide a solution better than MIPv6 for inter-MAP domain handover.
Fast Handover for MIPv6 (FMIPv6; see IETF RFC 4260 herein included by reference) aims at improving handover latency of the MIPv6 protocol. FMIPv6 necessitates a proper first registration of the MN with a first access router (PAR) as described above. Upon detection of movement of the MN towards a second access router (NAR), a temporary CoA address (nCoA) to be validated by the NAR is assigned to the MN before breakage of its connection with PAR. The DAD and, potentially, RR tests are performed while the MN is moving between the PAR and the NAR, i.e. while the MN is connected to the PAR. Still upon detection of movement of the MN towards the NAR, the MN sends a Fast Binding Update (FBU) to the PAR. The PAR, in turn, starts the setup of a bidirectional tunnel by sending a Handover Initiate (HI) from the PAR to the NAR and waiting for a Handover Acknowledgment (HACK) from the NAR. Once the HACK is received at the PAR, it sends a Fast Binding Acknowledgment (FBACK) to the MN. The PAR thereafter forwards traffic received for the MN on the tunnel thereby reducing the number of lost packets. Once the MN reaches the NAR, it resumes its communication with a CN. Then, the MN completes a BU with the CN and/or its Home Agent (HA). The tunnel is thereafter torn down and the MN starts using its nCoA.
FMIPv6 presents multiple flaws such as, for instance, a weak mechanism of movement detection. Since movement cannot be properly predicted, the mechanism cannot be properly triggered and is thus rarely used to its optimal potential. Furthermore, even if it is assumed to be properly triggered, FMIPv6 also causes problems of Quality of Service (QoS) management and scalability. In tested implementations, FMIPv6 further loses packets in the period where the MN is disconnected from the PAR and not yet connected to the NAR even if the tunnel exists. On other hand, in case of fast movement of the MN, the MN could arrive under the NAR much before the completion of tunnel setup. As a result, traffic may never reach the MN thereby causing packet loss. While FMIPv6 improves the performance of MIPv6 based on movement anticipation, it does not sufficiently meet the requirement of delay sensitive applications. Furthermore, the tunnel management in FMIPv6 is problematic given, for instance, the lack of precision of the trigger mechanism.
A mix of HMIPv6 and FMIPv6 also exists, but does not either provide for a solution sufficient for delay sensitive applications (e.g., problem with inter-domain handover, QoS management, scalability, etc.).
The foregoing is a discussion of solutions in view of the MIPv6 standard, which is usually referred to at the level 3 of the Open System Interconnection (OSI) model. However, the same concern in relation to handover for delay sensitive applications in data networks can be seen from other perspectives (e.g., from the OSI layer 2 or from other level 3 standards such as IPv4). Unfortunately, solutions are yet to be seen concerning handover procedure for delay sensitive applications in those perspectives as well.
As can be appreciated, there is a need for a handover mechanism that can increase fulfillment of the requirements of delay sensitive applications in data network environments.